IBIS Macromodel Task Group

Meeting date: 08 March 2022

Members (asterisk for those attending):
Achronix Semiconductor:       Hansel Dsilva
Amazon:                       John Yan
ANSYS:                      * Curtis Clark
                            * Wei-hsing Huang
Cadence Design Systems:     * Ambrish Varma
                              Jared James
Google:                       Zhiping Yang
Intel:                      * Michael Mirmak
                              Kinger Cai
                              Alaeddin Aydiner
Keysight Technologies:      * Fangyi Rao
                              Majid Ahadi Dolatsara
                            * Ming Yan
                              Radek Biernacki
                              Rui Yang
Luminous Computing            David Banas
Marvell                       Steve Parker
Mathworks (SiSoft):         * Walter Katz
                              Mike LaBonte
Micron Technology:          * Randy Wolff
                            * Justin Butterfield
Missouri S&T                  Chulsoon Hwang
Siemens EDA (Mentor):       * Arpad Muranyi
Teraspeed Labs:             * Bob Ross
Zuken USA:                  * Lance Wang

The meeting was led by Arpad Muranyi.  Curtis Clark took the minutes.

--------------------------------------------------------------------------------
Opens:

- None.

-------------
Review of ARs:

- Fangyi to propose language changes for PAM_Thresholds Usage Rules in
  BIRD213.1.
  - Done.  Arpad has sent out a draft 15 incorporating Fangyi's language.

--------------------------
Call for patent disclosure:

- None.

-------------------------
Review of Meeting Minutes:

Arpad asked for any comments or corrections to the minutes of the March 1st
meeting.  Michael moved to approve the minutes.  Ambrish seconded the motion.
There were no objections.

-------------
New Discussion:

BIRD213.1 draft 15, PAMn:
Arpad shared draft 15 and reviewed Fangyi's language changes.

Fangyi had noted an inconsistency, in the Usage Rules for PAM_Thresholds, in the
language used to describe the location of the "eyes".  The second paragraph of
the section described the progression of eyes:
   "The eye with the lowest threshold voltage is eye "1", the eye with the
    next threshold voltage up is eye "2", ..."
In the bulleted list that followed, however, the definitions of the voltage
ranges corresponding to symbol values referred to rows in the PAM_Thresholds
Table.  That is, eye 1 corresponds to the value in row 1 of the
PAM_Thresholds parameter, eye 2 corresponds to row 2, etc.

Fangyi's new language in the second paragraph associated eyes with rows in the
Table instead of referring to the magnitude of the threshold voltages (e.g.,
row 1 instead of "lowest threshold voltage" corresponds to eye 1).  No one
objected to these changes, which made the paragraph consistent with the bulleted
list that followed.  Fangyi noted that this language allowed the possibility of
the model returning threshold voltages that were out-of-order (not monotonically
increasing with row).  Randy noted several places in the BIRD where "Row" was
capitalized and should not have been, and Arpad changed them to "row".

Fangyi said that based on a suggestion from Curtis he thought we should change
any instances of "symbol value" (e.g., in the Usage Rules: for PAM_Thresholds)
to "symbol voltage".  Curtis had asked if we should avoid use of "detected as
symbol value N", since we are trying to keep IBIS out of any involvement in
mapping.  Curtis had suggested replacing "symbol value" with "voltage level".
Fangyi agreed with the idea of replacing "symbol value", but he suggested
replacing it with "symbol level".  Fangyi said "symbol level" better captured
the concept of discrete symbol levels, while "voltage level" implied a
continuum.  Curtis agreed with Fangyi's "symbol level" suggestion.  No one in
the group objected to the change, and Arpad replaced instances of "symbol value"
with "symbol level".

The group resumed the previous week's discussion of Table vs. String for the
PAM_Thresholds and PAM_Offsets parameters.  Curtis recalled that some attendees
had expressed concern about the difficulty in defining the contents of the
parameters if we instead used Type String, and some discussion had suggested
there were significant differences in what the model returned in the case of
String vs. Table.  Curtis said he had gone back to review IBIS 7.1 and what the
contents of the parameters_out string returned by the model would be.  In fact,
since a multi-row Table is collapsed to a single sequence of values when passed
in or out of a model, the contents of the parameters_out string returned by the
model were almost identical.  For example, a PAM4 case was shown:

With a String parameter as proposed by Ambrish, the format of the
PAM_Thresholds portion of the parameters_out string would be: 
   (PAM_Thresholds "-0.333 0.0 0.333")

With the Table parameter, the format of the PAM_Thresholds portion of the
parameters_out string would be:
   (PAM_Thresholds -0.333 0.0 0.333)
   
The returned values are identical, except for the surrounding quotes.  Since
they are almost identical, and the String parameter is simpler overall, Curtis
said he was further inclined to support Ambrish's motion (which had been
withdrawn) to use a String parameter instead of a Table.

Ambrish said he thought a Table was overkill in this application and offered no
advantages.  He said he thought it was simpler in the .ami file, for the model
maker, and in the language in the specification to use String parameters for
PAM_Thresholds and PAM_Offsets.  Walter said he had come around to agree with
Ambrish.

Bob said all the points about simplicity were well taken.  He said one concern
he had was that the existing PAM4_UpperThreshold, PAM4_CenterThreshold, and
PAM4_LowerThreshold were Floats, and now we would be using a String Type for the
new parameters.  Ambrish and Curtis agreed, but they noted that the existing
PAM4 threshold parameters used a separate parameter for each threshold, and the
new PAM parameters would be returning multiple values whether a Table or String
parameter were used.

Arpad asked if we had agreement to use String instead.  Ambrish moved to use
String parameters instead of Tables for PAM_Thresholds and PAM_Offsets.  Walter
seconded.  There were no objections.  Arpad said he would send the current draft
with today's changes to the ATM list as draft 16.  Ambrish took an AR to make
the changes necessary to switch from Tables to Strings.

Bob noted that one other difference with the existing PAM4 threshold parameters
was that they are not just Usage Out as the new PAM parameters are.  Walter
agreed.

AMI Parameter tree root name clarifications BIRD draft:
Michael reviewed comments Arpad had sent to the ATM list in response to draft 3.

Arpad had asked if:
  "This root name shall be compared to the built-in root name of the receiving
   algorithmic model."
   
should be (change "of" to "by"):
  "This root name shall be compared to the built-in root name by the receiving
   algorithmic model."
   
Michael said this was a good question and raised the issue of directionality.
He added language explicitly stating that the value passed in via parameters_in
is checked by the model, and the value the model returns through parameters_out
is checked by the EDA tool.

Arpad's next question had been, "What should the model do if it finds a
mismatch?"  Michael said we could mandate that the model must return zero (the
return value of the called function) if it detects a mismatch.  Arpad said his
question had been more about whether detecting a mismatch was a reason for the
model to fail.  Michael suggested that he thought it should not be a reason to
force the model to fail.  He said this had been discussed at length in the
Quality task group.  He said you might have the option of AMI tree selectors,
and root names might be a way of selecting between them.  He said we might not
want to legislate that flexibility out of existence.

Arpad noted that the directionality BIRD that had added Executable_Tx and
Executable_Rx allowed the possibility of a dual executable model that worked
with Tx and Rx .ami files.  Arpad asked if we wanted to obligate the model to
return an error on mismatches.  Curtis agreed, and he asked if we should change
any language referring to models checking the value of root name against their
internal root name to allow the possibility of a single executable model
accepting multiple root names (plural).  Michael said the Tx and Rx direction
.ami files could each use the same root name.  Arpad said more discussion on
this topic was needed.  Michael said he would send out draft 4. 

- Ambrish: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.

AR: Arpad to send draft 16 of BIRD213.1 to the ATM list.
AR: Ambrish to add Table -> String changes to draft 16.
AR: Michael to send draft 4 of the Root Name Clarifications BIRD to ATM.
    
-------------
Next meeting: 15 March 2022 12:00pm PT
-------------

IBIS Interconnect SPICE Wish List:

1) Simulator directives
